系列：《我用 AI 養出一個 AWS 維運同事》｜撰於 2026-09｜Kiro IDE 1.0
真實案例，客戶與叢集名稱已去識別化。數字為實際量級。

帳單來的那天

有個大型的 EKS 正式叢集，某個月帳單一開，CloudWatch 那條線直接跳到一個月六千多美金。這不是慢慢漲上來的，是某個月「碰」一聲冒出來的。

維運看到這種跳動，第一反應通常是「是不是被打了」「是不是哪個服務爆量」。但這種猜法很浪費時間。我把這件事丟給 AI 同事，讓它幫我用多月份對比把費用拆開來看。

第一步：拆帳單，別用「服務」看，要用「用量類型」看

這是我想先分享的一個維運心法。CloudWatch 帳單如果你只看「CloudWatch 總共多少錢」，你什麼都查不出來。要拆到 USAGE_TYPE（用量類型） 這一層。

AI 拉出來的對比長這樣（量級示意）：

一看就破案一半了：這三筆是同一個月一起冒出來的——代表那個月有人裝了、或打開了某個「全都要」的監控套件。

順帶更正一個很多人（包括以前的我）會誤會的名詞：帳單上那個 DataProcessing-Bytes 看起來像「流量處理費」，其實它是 CloudWatch Logs 的攝取費（log 寫進去的錢）。名字取得很有誤導性，我也是查官方帳單文件才確認的。

第二步：找真凶——log 一天七億五千萬筆

Log 攝取為什麼從 8 塊變 5500 塊？AI 進一步用 Logs Insights 幫我按「哪個容器產最多 log」統計，結果嚇死人：

這個叢集的 application log，一天產生約 7.5 億筆，而且高度集中在三個容器（加起來佔九成）。不是那種「到處都有一點雜訊」的問題，是三個大戶在狂噴。

這裡有個查證踩過的雷值得講：我一開始想用某個指標的「30 天總量」去估 log 量，結果數字兜不攏（估出來 2GB，但實際儲存量顯示近 800GB，差了幾百倍）。後來發現是取樣週期設太大導致數值失真，改成「按天取多點再加總」才對得上。查用量千萬別只取一個大區間的單點，會被平均值騙。

第三步：最關鍵的一問——「這些 log 有沒有別的來源？」

找到真凶後，最直覺的解法是「降低那三個容器的 log 等級」或「用 Fluent Bit 取樣丟棄一部分」。但我沒有急著動手，而是先問了應用團隊一個問題：

「這些 application log，除了進 CloudWatch，有沒有寫去別的地方？」

答案讓整件事變超簡單：這些 log 應用本來就直接寫進資料庫了，CloudWatch 這份根本是重複的。

那還留它幹嘛？直接把 application log 完全關掉（設定裡 containerLogs.enabled: false），零 debug 風險——因為 log 一份都沒少，只是不再多付一次錢請 CloudWatch 存重複的。

第四步：砍 log ≠ 砍監控，這兩條路互不影響

這是整個案子我最想強調的技術點。很多人以為「關掉 CloudWatch log」＝「什麼都看不到了」。錯。

在這套監控套件裡，「應用 log」和「pod/容器層的效能監控」走的是完全不同的管道：

• Application log → 走一條日誌管線（可以整條關掉）
• Pod/容器指標（enhanced Container Insights）→ 走另一條指標管線

所以我的最終決定是：砍掉重複的 application log、但保留 pod 層的效能監控。監控該有的還在，白花的 log 錢砍光。兩件事分開，各關各的。

結果

粗估：一個月約 $6,900 → 約 $630，省下九成。 而且因為 log 本來就有資料庫那份備份，這刀砍下去完全沒有可觀測性的損失。

這個案子最後變成一條「知識」

破完案，我沒讓這些教訓隨對話蒸發。它們被沉澱進了 CloudWatch 的錯題本（Day 5 講的那套），現在只要一提到 CloudWatch 費用，這些雷會自動回到 AI 腦袋裡：

• 拆帳單要用 USAGE_TYPE，不能只看服務層
• DataProcessing-Bytes 是 log 攝取費，不是流量費
• 砍 log 前先問「有沒有別的來源」，有備份才能放心全砍
• log 管線和監控管線分開，可以只砍 log 保留監控

下次再遇到類似的費用暴衝，它不用從頭破一次案。 這就是「錯題本」對維運的真正價值——不是記帳，是讓每次踩坑都變成往後的捷徑。

帶走的三個重點

1. 費用暴衝先拆 USAGE_TYPE。 只看服務層永遠找不到真凶。
2. 砍 log 前先問「有沒有別的來源」。 有備份就能零風險全砍，沒有才需要取樣或降級。
3. log 和監控是兩條管線。 可以只砍重複的 log，保留該有的監控，別一刀全關。

明天換個題目——講講我怎麼讓 AI 記得「我到底管哪些 AWS 帳號、裡面有什麼」，而且這份帳號清單還會自己更新。

✍️ 關於作者：康子晉，做 AWS 維運與架構，日常跟一堆帳號、費用、架構圖為伍。這個系列記錄我怎麼把 AI 從「會聊天」調教成「能扛維運的同事」。
🔗 LinkedIn